Skip to main content

GitOps with AKS and FluxCD

GitOps is a methodology that treats Git repositories as the "Single Source of Truth" for managing and deploying infrastructure and application configurations. This document explains how to practice GitOps using Azure Kubernetes Service (AKS) and FluxCD, along with best practices.

What is GitOps​

GitOps applies DevOps best practices to infrastructure automation.

Key Features​

  1. Declarative Definition: Manage the entire system state declaratively in Git (e.g., YAML).
  2. Version Control: Change history, reviews, and rollbacks are handled entirely within Git.
  3. Automated Application: Automatically synchronize the state in Git with the state of the cluster.
  4. Continuous Reconciliation: Detect drift (configuration divergence) and correct it to the desired state.

Overview of FluxCD​

FluxCD is a CNCF (Cloud Native Computing Foundation) Graduated project and is an open and extensible continuous delivery solution for Kubernetes.

FluxCD Components​

  • Source Controller: Fetches artifacts from sources like Git or Helm repositories.
  • Kustomize Controller: Applies Kustomize or plain YAML.
  • Helm Controller: Manages Helm chart releases.
  • Notification Controller: Handles event notifications (Slack, Teams, etc.).

Leveraging Kustomize​

Kustomize is a configuration management tool for customizing Kubernetes manifests (YAML files). Unlike template engines like Helm, it modifies settings by layering another YAML file (patch) on top without changing the original YAML file.

Base and Overlays​

Important concepts in Kustomize management are Base and Overlays.

  • Base: A set of manifests that form the basis of the application. Describes settings common to all environments (such as Deployment and Service definitions).
  • Overlays: References Base and defines differences (patches) for each environment. For example, it is used to set different replica counts, resource limits, and environment variables for the development environment (Dev) and production environment (Prod).

This mechanism eliminates the need to copy and paste YAML files for each environment, achieving deduplication of settings and improved maintainability.

Architecture​

The basic architecture of GitOps using FluxCD on AKS is as follows:

Process Flow​

  1. Developers modify application code and push to the App Repository.
  2. The CI pipeline runs to test, build, and create a container image.
  3. The image is pushed to Azure Container Registry (ACR).
  4. The CI pipeline updates the manifest (e.g., Deployment image tag) in the Config Repository.
  5. FluxCD in AKS detects changes in the Config Repository (or polls periodically).
  6. FluxCD applies the new configuration to the cluster (Reconcile).
  7. Kubernetes pulls the new image from ACR and updates the Pods.

Setting up FluxCD on AKS​

In AKS, you can easily install Flux as a Cluster Extension.

Installation via Azure CLI​

# Register required extension providers
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.KubernetesConfiguration

# Install Flux extension
az k8s-extension create \
    --name flux \
    --extension-type microsoft.flux \
    --scope cluster \
    --resource-group <ResourceGroup> \
    --cluster-name <AKSClusterName> \
    --cluster-type managedClusters

Directory Structure Best Practices​

The structure of the GitOps repository (Config Repository) directly impacts scalability and manageability.

├── apps/                   # Base configuration per application
│   ├── base/
│   │   ├── my-app/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   └── overlays/           # Differences per environment
│       ├── dev/
│       ├── staging/
│       └── prod/
├── infrastructure/         # Infrastructure components (Ingress, Cert-Manager, etc.)
│   ├── base/
│   └── overlays/
└── clusters/               # Flux configuration per cluster
    ├── dev-cluster/
    │   ├── flux-system/
    │   ├── apps.yaml       # Reference to apps directory
    │   └── infra.yaml      # Reference to infrastructure directory
    └── prod-cluster/

Best Practices​

1. Separation of Application Code and Configuration​

It is recommended to separate the application source code repository from the configuration repository managing Kubernetes manifests. This clarifies the responsibilities of CI (Build) and CD (Deploy) and prevents infinite loops (Build -> Deploy -> Commit -> Build...).

2. Leveraging Kustomize​

Use Kustomize to manage configuration differences between environments (Dev, Staging, Prod). Sharing base configurations reduces duplicate code and improves maintainability.

3. Secret Management​

Do not include raw passwords or API keys in Git repositories. Consider one of the following methods:

  • Sealed Secrets: Encrypt with a public key and commit to Git. The controller in the cluster decrypts it with a private key.
  • Azure Key Vault Provider for Secrets Store CSI Driver: Mount secrets directly from Azure Key Vault.

4. Drift Detection and Notification​

Configure Flux notification features to notify Slack or Microsoft Teams of synchronization failures or drift occurrences. This allows for early detection of issues.

5. Automating Image Updates​

Using Flux's Image Automation Controller, you can automatically rewrite and commit manifests in the Git repository when a new tag is pushed to ACR. This eliminates the need for write operations to Git from the CI pipeline.

Summary​

By combining AKS and FluxCD, you can build a robust and auditable delivery pipeline. Centering on Git increases operational transparency and facilitates cluster state management.